Today’s modern systems have to talk to each other, exchange data and share services. Today, entire business models are based on the exchange of information via well-defined interfaces, also known as application programming interfaces (API). So, now that our world has been turned upside down by software, it’s time to use it as a foundation for further change and use APIs to embrace the next revolution: APIs are eating the world!

Let’s take Uber as an example. Uber’s core business is to bring together people who want to travel from A to B and drivers who want to provide this service. This is very similar to the taxi business, except that Uber has no taxis of its own and has not hired any drivers.

In the same way that Uber only accesses third parties who offer and consume the services, Uber also acts with regard to its corporate IT. Uber concentrates on developing the most important thing for them themselves (a mobile app with a high UX factor). For all other processes, Uber relies on external service providers and services. These are all connected to each other via an API.

APIs have changed the modern business world. For us mere “techies”, this evolution has created new challenges and requirements. First of all, if we want to get involved in the API business and develop or integrate it into our systems, it requires a higher level of understanding for our respective business domains. It is no longer enough just to be the expert for JPA or JSF and know which parameters to configure. APIs have a clear relevance to the domain and we need to understand this.

The technologies that APIs bring along are often not completely new technologies. We already know many concepts from the past and have already worked with them. Only the specifications change as to how we can and should use these technologies. For example, the serialization of data to transfer between two systems is nothing new. We have been doing this with XML for decades. In recent years, JSON has emerged as an alternative. Likely, we will deal with other formats such as Afro and others in the future. The topic of serialization as such remains, only the way in which we serialize the data changes.

With regards to security, there are new specifications for existing concepts and technologies. The authentication and authorization of access to and queries from different systems via APIs and tokens is nothing new. SAML is an XML-based standard was already standardized in the early 2000s. SAML is powerful, but focuses more on internal enterprise solutions. For communication across network boundaries and between heterogeneous systems, specifications such as OAuth and OpenID Connect have evolved from the changed requirements. However, they are also token-based.

Nevertheless, it is not only putting a new coat of paint on an old idea. A whole host of new technologies, new programming languages, and entire ecosystems continue to evolve, all focusing on solving problems with very specific requirements. We must not rest easily on our laurels.

New technologies, however small and insignificant they may initially appear, are now being created faster than ever before. Many of these disappear as quickly as they have come into existence, but one or two tools survive. And it is precisely these tools that can be used to solve future challenges. Familiarity with these tools can help us gain the necessary competitive edge in the business world.

We don’t have to be experts in every new technology when it comes out. But we should go through our world with open eyes and open minds.
To consume other APIs, we first need to get an overview of the different services on many different levels. APIs are partly a business process and partly a technical tool. Not all APIs work equally and on identical levels. We have to ask ourselves which APIs are relevant for our application.

How to develop Web APIs?

Explore the API Development Track

Learn more

If we want to offer (public) APIs, we have to deal with two more new topics: API design and API management.

API design is mainly about creating an easy-to-learn and easy-to-use API that will be used by as many consumers as possible. In addition to its simplicity, it must also be difficult to use incorrectly. A company has pretty much one shot at this, because once an API is public and it is used, it can only be changed with great difficulty. An API must be extensible and thus ensure compatibility over several change cycles. And even if it is essentially the machines (or “systems”) that communicate via an API, the API is “read” by other developers. Topics such as documentation and naming (for objects, methods, attributes, etc.) suddenly become the focus of attention. It is not an easy task, but it bears a lot of responsibility.

But we are not only responsible for the design of the API at the beginning of its lifecycle. An API must be managed throughout its entire lifecycle and in several ways. These include topics such as security (access control, but also sealed test environments/sandboxes), performance, caching and last but not least, SLAs, which we as a provider can assure our consumers. What used to be just one aspect of our daily work now becomes the focus of our activities.